User reported visible frame-rate drop while scrolling YouTube with
the accessibility service active. Cause: YouTube fires
TYPE_WINDOW_CONTENT_CHANGED at ~30 Hz during scroll, and v1.0.7 ran
the full 1200-node tree walk on every event. That's ~36k node
inspections per second while scrolling — enough to push the system
past the 16ms frame budget.

Two changes:

1. Throttle walks for content-changed events to one every 250ms.
   State-changed events (rare; fire when entering Shorts /
   navigating screens) keep being processed immediately so detection
   latency on the path that matters is unchanged.

2. Reduce MAX_NODES_PER_WALK from 1200 to 600. Empirically the
   relevant Shorts UI lives in the first few hundred nodes; the
   1200 cap was just safety margin we don't need.

Net effect for the user: while on YouTube home / scrolling the
feed, we walk ~4×/sec instead of ~30×/sec, and each walk visits
half as many nodes. Total CPU work in the steady state is about
1/15th of v1.0.7. Detection on Shorts open is unaffected since
that triggers a STATE_CHANGED event which still walks immediately.

Bump versionCode 8 → 9, versionName 1.0.7 → 1.0.8.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>